Generally, an application stack may be implemented using multiple tiers, including a web tier (e.g., web server), an application tier (e.g., an application server), and a database tier (e.g., a database server). Software components may be independently running on each of these tiers. The software components of the various tiers may be configured to communicate within the same server or across multiple servers. Further, these servers may be virtual machines or physical machines, running within the same datacenter or across datacenters in different regions. Over time, the application stack may need to be updated, for example, to fix bugs or add functionality to services provided using the application stack. Updating the application stack typically involves hiring vendors to update and test the different software components of each tier to test for issues arising out of installing the software components. However, this updating process is burdensome on network resources because complex application stacks can be very large (e.g., 1 terabyte) and the servers typically need to be taken offline for long periods of time to enable testing of the servers.
Even in application environments without a traditional application stack, applications can have dependencies on various resources or components in the cloud network environment. Updating the application by overwriting the image of the application may destroy these dependencies, causing further bugs and/or failures. After the application image was overwritten, the manager of the application environment would need to follow up on the update process by reconnecting or reestablishing all of those dependencies. Such a follow-up process is tedious in general, but even more tedious in larger application environments with large numbers of these dependencies.